Master the critical knowledge areas for project success and PMP certification
Risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives such as scope, schedule, cost, and quality.
Project Risk Management includes the processes of conducting risk management planning, identification, analysis, response planning, response implementation, and monitoring risk on a project. The objectives are to increase the likelihood and impact of positive events and decrease the likelihood and impact of negative events in the project.
Define approach and plan activities
Determine which risks may affect the project
Prioritize individual risks
Numerically analyze overall project risk
Develop options and actions
Execute agreed-upon risk response plans
Track identified risks and identify new risks
The process of defining how to conduct risk management activities for a project. The key benefit is that it ensures that the degree, type, and visibility of risk management are commensurate with both the risks and the importance of the project to the organization.
| Component | Description | Key Considerations |
|---|---|---|
| Risk Strategy | General approach to managing risk on the project | Risk appetite, risk tolerance, risk thresholds |
| Methodology | Defines approaches, tools, and data sources | Risk identification techniques, analysis methods |
| Roles and Responsibilities | Defines lead, support, and team members | Risk owner, risk actionee assignments |
| Funding | Resources needed for risk management activities | Contingency reserves, management reserves |
| Timing | When and how often risk management processes performed | Risk review meetings, reporting frequencies |
| Risk Categories | Ways risks may be grouped | Risk Breakdown Structure (RBS) |
| Stakeholder Risk Appetite | Measurable risk appetite statements | Risk thresholds for different objectives |
| Definitions of Risk Probability and Impacts | Risk probability and impact scales | Probability and Impact Matrix |
| Reporting Formats | How risk management results documented | Risk register, risk reports templates |
| Tracking | How risk management activities recorded | Risk auditing and lessons learned processes |
Situation: You are the project manager for a new e-commerce platform development. The executive sponsor is risk-averse, and the project has a tight deadline with significant revenue implications.
Challenge: How do you tailor your risk management approach?
Solution:
The process of identifying individual project risks as well as sources of overall project risk, and documenting their characteristics. The key benefit is the documentation of existing individual project risks and the sources of overall project risk.
A Risk Breakdown Structure (RBS) is a hierarchical representation of potential sources of risk on a project.
| Category Level 1 | Category Level 2 | Example Risks |
|---|---|---|
| Technical | Requirements | Requirements volatility, unclear requirements |
| Technology | Unproven technology, integration complexity | |
| Quality | Performance issues, defect rates | |
| External | Regulatory | Compliance changes, permit delays |
| Market | Competition, economic conditions | |
| Environmental | Weather, natural disasters | |
| Organizational | Resources | Resource availability, skill gaps |
| Funding | Budget cuts, funding delays | |
| Prioritization | Competing projects, changing priorities | |
| Project Management | Planning | Inadequate planning, scope creep |
| Communication | Poor communication, stakeholder misalignment | |
| Control | Inadequate monitoring, change control issues |
Situation: You are managing a hospital construction project. You need to identify risks systematically.
Risk Identification Workshop Results:
Key Learning: Use multiple identification techniques and involve diverse stakeholders for comprehensive risk identification.
The Risk Register is a project document in which the results of risk analysis and risk response planning are recorded.
| Risk Register Component | Description | Example |
|---|---|---|
| Risk ID | Unique identifier for the risk | R001, R002, etc. |
| Risk Description | Clear statement of the risk | "Key developer may leave the team" |
| Risk Category | Source or type of risk | Organizational/Resources |
| Root Cause | Fundamental reason for the risk | "Market demand for skills" |
| Probability | Likelihood of occurrence | High (0.7), Medium (0.5), Low (0.2) |
| Impact | Effect on project objectives | High, Medium, Low |
| Risk Score | Probability × Impact | 0.35 (High probability × Medium impact) |
| Risk Owner | Person responsible for monitoring | Project Manager, Team Lead |
| Response Strategy | Planned response approach | Mitigate, Transfer, Accept, Avoid |
| Response Actions | Specific actions to implement | Cross-training, retention bonus |
| Status | Current state of the risk | Open, Closed, Monitoring |
The process of prioritizing individual project risks for further analysis or action by assessing their probability of occurrence and impact as well as other characteristics. The key benefit is that it focuses efforts on high-priority risks.
| Scale | Probability Range | Description |
|---|---|---|
| Very High (0.9) | 81-99% | Very likely to occur |
| High (0.7) | 61-80% | Likely to occur |
| Medium (0.5) | 41-60% | May occur |
| Low (0.3) | 21-40% | Unlikely to occur |
| Very Low (0.1) | 1-20% | Very unlikely to occur |
| Scale | Cost Impact | Schedule Impact | Scope Impact |
|---|---|---|---|
| Very High (0.8) | >20% increase | >20% schedule delay | Major scope reduction |
| High (0.4) | 10-20% increase | 10-20% schedule delay | Scope reduction |
| Medium (0.2) | 5-10% increase | 5-10% schedule delay | Minor scope reduction |
| Low (0.1) | 1-5% increase | 1-5% schedule delay | Minimal scope impact |
| Very Low (0.05) | <1% increase | <1% schedule delay | No scope impact |
The Probability and Impact Matrix is a grid for mapping the probability of occurrence of each risk and its impact on project objectives if that risk occurs.
| Probability / Impact | Very Low (0.05) | Low (0.1) | Medium (0.2) | High (0.4) | Very High (0.8) |
|---|---|---|---|---|---|
| Very High (0.9) | 0.045 | 0.09 | 0.18 | 0.36 | 0.72 |
| High (0.7) | 0.035 | 0.07 | 0.14 | 0.28 | 0.56 |
| Medium (0.5) | 0.025 | 0.05 | 0.10 | 0.20 | 0.40 |
| Low (0.3) | 0.015 | 0.03 | 0.06 | 0.12 | 0.24 |
| Very Low (0.1) | 0.005 | 0.01 | 0.02 | 0.04 | 0.08 |
Situation: You have identified multiple risks for a cloud migration project. Here's how to prioritize them:
| Risk | Probability | Impact | Risk Score | Priority |
|---|---|---|---|---|
| Data migration failure | Medium (0.5) | Very High (0.8) | 0.40 | High |
| Security vulnerability | Low (0.3) | High (0.4) | 0.12 | Medium |
| Performance degradation | High (0.7) | Medium (0.2) | 0.14 | Medium |
| User training delays | Medium (0.5) | Low (0.1) | 0.05 | Low |
Action Plan: Focus immediate attention on data migration failure risk, actively manage security and performance risks, monitor user training risk.
Evaluate the degree to which the data about individual project risks is accurate and reliable. Consider:
Group risks by sources of risk to determine areas of the project most exposed to uncertainty:
Identify risks requiring near-term responses. Indicators include:
The process of numerically analyzing the combined effect of identified individual project risks and other sources of uncertainty on overall project objectives. The key benefit is that it quantifies overall project risk exposure and provides additional quantitative risk information to support risk response planning.
Quantitative risk analysis is performed on risks that have been prioritized through qualitative risk analysis as potentially and substantially impacting the project's competing demands. It is not always required and depends on project complexity, importance, and stakeholder requirements.
Sensitivity Analysis helps determine which individual project risks or other sources of uncertainty have the most potential impact on project outcomes. It examines the extent to which the uncertainty of each project element affects the objective being examined.
Tornado Diagram: A special type of bar chart used in sensitivity analysis that shows the relative importance of variables. Variables are ordered by the degree of their impact on the project objective.
EMV is a statistical technique that calculates the average outcome when the future includes scenarios that may or may not happen.
Example: A risk has a 30% probability of occurring and would cost $100,000 if it occurs:
Situation: You need to choose between two development approaches for a software project:
| Option | Scenario | Probability | Cost | EMV |
|---|---|---|---|---|
| Option A: In-house | Best case | 30% | $200,000 | $60,000 |
| Most likely | 50% | $300,000 | $150,000 | |
| Worst case | 20% | $500,000 | $100,000 | |
| Total EMV for Option A | $310,000 | |||
| Option B: Outsourced | Best case | 40% | $250,000 | $100,000 |
| Most likely | 45% | $350,000 | $157,500 | |
| Worst case | 15% | $450,000 | $67,500 | |
| Total EMV for Option B | $325,000 | |||
Decision: Choose Option A (in-house) as it has the lower EMV ($310,000 vs $325,000).
Monte Carlo Simulation uses a model that translates uncertainties specified at a detailed level into their potential impact on the overall project. The simulation runs the model thousands of times to provide statistical distribution of the calculated results.
Key Benefits:
| Aspect | Contingency Reserves | Management Reserves |
|---|---|---|
| Purpose | Address identified risks | Address unidentified risks and scope changes |
| Control | Project manager authority | Management/sponsor authority |
| Inclusion in Baseline | Included in cost/schedule baseline | Not included in baseline |
| Calculation Method | EMV, percentage, Monte Carlo | Percentage of total project cost |
| Typical Size | 5-15% of project cost | 5-10% of project cost |
The process of developing options, selecting strategies, and agreeing on actions to address overall project risk exposure, as well as to treat individual project risks. The key benefit is that it identifies appropriate ways to address overall project risk and individual project risks.
Avoid eliminates the threat by eliminating the cause. Examples include changing the project plan, adding resources, or using proven technology instead of cutting-edge technology.
When to Use: High-impact threats that cannot be effectively mitigated or transferred.
Example: Removing a risky work package from the project scope to avoid potential delays.
Transfer shifts the impact of a threat to a third party, along with ownership of the response. Examples include insurance, warranties, guarantees, and outsourcing.
When to Use: When another party is better positioned to manage the risk.
Example: Purchasing insurance for weather-related construction delays.
Mitigate reduces the probability and/or impact of a threat. It's often more effective than trying to repair the damage after the threat has occurred.
When to Use: Most common strategy when avoidance and transfer are not feasible.
Example: Cross-training team members to reduce the impact of key person dependency.
Accept acknowledges the existence of a threat but takes no proactive action. Can be active (establishing contingency reserves) or passive (documenting the strategy).
When to Use: Low-priority risks or when other strategies are not cost-effective.
Example: Accepting the risk of minor scope changes and establishing a small contingency reserve.
Exploit ensures that the opportunity definitely happens. Examples include assigning the organization's most talented resources to the project.
Example: Adding more resources to finish ahead of schedule and capture an early completion bonus.
Share allocates some or all of the ownership of an opportunity to a third party who is best able to capture the opportunity for the benefit of the project.
Example: Forming a joint venture with another company to capitalize on a market opportunity.
Enhance increases the probability and/or positive impacts of an opportunity. It focuses on identifying and maximizing key opportunity drivers.
Example: Providing incentives to suppliers for early delivery to take advantage of favorable market conditions.
Accept an opportunity means being willing to take advantage of the opportunity if it arises but not actively pursuing it.
Example: Being prepared to add scope if additional funding becomes available.
Contingent Response Strategies are responses that are only implemented if certain predefined conditions or trigger events occur.
Components:
Project: New product launch with aggressive timeline
| Risk | Type | Strategy | Response Actions | Trigger/Condition |
|---|---|---|---|---|
| Key supplier delay | Threat | Mitigate | Identify backup suppliers, establish buffer inventory | Supplier reports potential delay |
| Regulatory approval delay | Threat | Transfer | Hire regulatory consulting firm | Application submitted |
| Early market opportunity | Opportunity | Exploit | Accelerate development, add resources | Competitor delays product |
| Technology breakthrough | Opportunity | Enhance | Increase R&D funding, patent filing | Research milestone achieved |
| Minor feature delays | Threat | Accept | Document decision, establish small reserve | Feature testing failure |
The process of implementing agreed-upon risk response plans. The key benefit is that it ensures that agreed-upon risk responses are executed as planned in order to address overall project risk exposure, minimize individual project threats, maximize individual project opportunities, and improve project success.
The process of monitoring the implementation of agreed-upon risk response plans, tracking identified risks, identifying and analyzing new risks, and evaluating risk process effectiveness throughout the project. The key benefit is that it enables project decisions to be based on current information about overall project risk exposure and individual project risks.
Risk Audits are examinations of the effectiveness of risk responses in dealing with identified risks and their root causes, as well as the effectiveness of the risk management process.
Risk Audit Focus Areas:
Project: Enterprise software implementation
| Risk ID | Risk Description | Current Status | Trend | Response Status | Next Review |
|---|---|---|---|---|---|
| R001 | Data migration complexity | High | ↑ Increasing | Mitigation in progress | Weekly |
| R002 | User adoption resistance | Medium | → Stable | Training plan activated | Bi-weekly |
| R003 | Integration challenges | Low | ↓ Decreasing | Mitigation effective | Monthly |
| R004 | Performance issues | Critical | New Risk | Response planning | Daily |
Key Actions: Immediate escalation for R004, continue mitigation for R001, maintain monitoring for others.
Quality is the degree to which a set of inherent characteristics fulfills requirements. Quality management includes all activities that determine quality policies, objectives, and responsibilities.
Project Quality Management includes the processes for incorporating the organization's quality policy regarding planning, managing, and controlling project and product quality requirements in order to meet stakeholders' expectations. It supports continuous process improvement activities as undertaken on behalf of the performing organization.
Identify quality requirements and standards
Execute quality management plan
Monitor and control quality activities
Example: A software application may be high quality (meets all requirements) but low grade (basic features), or low quality (bugs, poor performance) but high grade (advanced features).
The process of identifying quality requirements and/or standards for the project and its deliverables, and documenting how the project will demonstrate compliance with quality requirements and/or standards. The key benefit is that it provides guidance and direction on how quality will be managed and verified throughout the project.
Compare the cost of the quality step to the expected benefit. The primary benefit of meeting quality requirements is less rework, higher productivity, lower costs, increased stakeholder satisfaction, and increased profitability.
Quality Cost Categories:
Project: Software development with quality investment decision
| Quality Investment Option | Prevention Costs | Appraisal Costs | Expected Failure Costs | Total Cost |
|---|---|---|---|---|
| Minimal Quality | $10,000 | $15,000 | $200,000 | $225,000 |
| Standard Quality | $25,000 | $30,000 | $75,000 | $130,000 |
| High Quality | $50,000 | $45,000 | $25,000 | $120,000 |
Decision: Invest in high quality approach - saves $105,000 compared to minimal quality and $10,000 compared to standard quality.
The Cost of Quality includes all costs incurred over the life of the product by investment in preventing nonconformance to requirements, appraising the product or service for conformance to requirements, and failing to meet requirements.
The Quality Management Plan is a component of the project management plan that describes how applicable policies, procedures, and guidelines will be implemented to achieve the quality objectives.
Quality Metrics are operational definitions that describe, in very specific terms, a project or product attribute and how the control quality process will measure it.
| Industry/Domain | Quality Metrics Examples | Measurement Method |
|---|---|---|
| Software Development | Defect density, code coverage, performance response time | Bugs per KLOC, % code tested, milliseconds |
| Construction | Safety incidents, rework percentage, schedule adherence | Incidents per 1000 hours, % rework, schedule variance |
| Manufacturing | First pass yield, customer returns, cycle time | % defect-free, returns per 1000 units, time per unit |
| Service Projects | Customer satisfaction, service availability, response time | Survey scores, % uptime, hours to respond |
The process of translating the quality management plan into executable quality activities that incorporate the organization's quality policies into the project. The key benefit is that it increases the probability of meeting the quality objectives as well as identifying inefficient and ineffective processes.
Quality Audits are independent reviews to determine whether project activities comply with organizational and project policies, processes, and procedures.
Project: Medical device development quality audit
| Audit Finding | Severity | Root Cause | Recommended Action |
|---|---|---|---|
| Design reviews not following standard process | High | Team unfamiliar with updated procedures | Immediate training, process update |
| Test documentation incomplete | Medium | Time pressure, unclear templates | Update templates, adjust schedule |
| Excellent risk management practices | Positive | Experienced project manager | Share best practice with other projects |
| Requirements traceability gaps | High | Tool limitations, manual processes | Implement requirements management tool |
Follow-up: Corrective action plan with timeline, responsible parties, and verification methods.
Design for X (DfX) is a set of design guidelines that focus on a specific aspect of design or downstream process.
Problem: Software application crashes during peak usage
Root Cause: Inadequate training and code review process
Solution: Implement comprehensive training program and mandatory code reviews with focus on memory management.
The process of monitoring and recording results of executing the quality management activities to assess performance and ensure the project outputs are complete, correct, and meet customer expectations. The key benefit is that it verifies that project deliverables and work meet the requirements specified by key stakeholders for final acceptance.
Statistical Sampling involves choosing part of a population of interest for inspection. Appropriate sample size can often reduce the cost of quality control.
Control Charts are graphic displays of process data over time and against established control limits. They have a centerline that assists in detecting a trend of plotted values toward either control limit.
| Component | Description | Purpose |
|---|---|---|
| Upper Control Limit (UCL) | Maximum acceptable variation | Identifies when process is out of control (high side) |
| Lower Control Limit (LCL) | Minimum acceptable variation | Identifies when process is out of control (low side) |
| Mean/Centerline | Average of the process measurements | Reference point for normal process performance |
| Specification Limits | Customer requirements boundaries | Define what customer will accept |
Process: Software defect detection during testing phases
| Week | Defects Found | Status | Action Required |
|---|---|---|---|
| 1-4 | 12, 15, 11, 14 | In Control | Continue monitoring |
| 5 | 23 | Out of Control | Investigate root cause immediately |
| 6-8 | 18, 19, 20 | Trending | Monitor closely, prepare corrective action |
| 9-12 | 13, 12, 14, 11 | Back in Control | Continue monitoring, document lessons learned |
Analysis: Week 5 spike triggered investigation revealing new developer onboarding issues. Corrective action (enhanced training) brought process back in control.
Inspection includes activities such as measuring, examining, and verifying to determine whether work and deliverables meet requirements and product acceptance criteria.
Quality Control Measurements are the documented results of control quality activities. They are used to analyze and evaluate how well the project's quality standards are being met.
| Measurement Type | Purpose | Examples | Frequency |
|---|---|---|---|
| Defect Metrics | Track defect trends and patterns | Defect density, defect age, defect severity | Daily/Weekly |
| Performance Metrics | Measure system performance | Response time, throughput, reliability | Continuous |
| Process Metrics | Evaluate process effectiveness | Review effectiveness, rework rate | Weekly/Monthly |
| Customer Metrics | Measure customer satisfaction | Satisfaction surveys, complaints | Monthly/Project End |
Verified Deliverables are completed deliverables that have been checked and confirmed for correctness through the control quality process. These verified deliverables are then submitted to the Validate Scope process for formal acceptance.
| Term | Definition | Example/Context |
|---|---|---|
| Risk | An uncertain event that, if it occurs, has positive or negative effect on project objectives | Key resource unavailability, technology failure |
| Risk Appetite | Degree of uncertainty an entity is willing to take on in anticipation of a reward | Aggressive vs conservative investment strategies |
| Risk Tolerance | Degree of variability willing to accept around specific objective | Schedule variance of ±2 weeks acceptable |
| Risk Threshold | Measure of level of uncertainty at which stakeholder may have specific interest | Escalate risks with impact >$50K to sponsor |
| Risk Owner | Person responsible for monitoring risk and implementing response strategy | Technical lead owns integration risk |
| Risk Actionee | Person responsible for implementing specific response actions | Developer implements code review process |
| Secondary Risk | Risk that arises as direct result of implementing risk response | Outsourcing creates communication risk |
| Residual Risk | Risk that remains after risk responses have been implemented | Reduced but not eliminated technical risk |
| Contingency Reserve | Budget for known risks (known unknowns) | 10% budget reserve for identified risks |
| Management Reserve | Budget for unknown risks (unknown unknowns) | 5% reserve for unidentified scope changes |
| Risk Breakdown Structure | Hierarchical representation of potential risk sources | Technical, External, Organizational, PM categories |
| Monte Carlo Simulation | Technique using random sampling to model uncertainty | Project completion probability analysis |
| Expected Monetary Value | Statistical calculation: Probability × Impact | 30% chance × $100K impact = $30K EMV |
| Tornado Diagram | Bar chart showing relative importance of variables | Sensitivity analysis visualization |
| Term | Definition | Example/Context |
|---|---|---|
| Quality | Degree to which inherent characteristics fulfill requirements | Software meets all functional specifications |
| Grade | Category for deliverables with same function but different characteristics | Economy vs luxury car models |
| Quality Assurance | Process-oriented approach to providing confidence that quality requirements will be fulfilled | Process audits, methodology compliance |
| Quality Control | Product-oriented approach to monitoring specific results | Testing, inspections, measurements |
| Prevention | Keeping errors out of the process or product | Training, process design, automation |
| Inspection | Examining work product to determine conformance to standards | Code reviews, design walkthroughs |
| Cost of Quality | Total cost of prevention, appraisal, and failure activities | Training + testing + rework costs |
| Control Chart | Graphic display of process data against control limits | Defect rate tracking over time |
| Upper Control Limit | Maximum acceptable process variation | Maximum acceptable defect rate |
| Lower Control Limit | Minimum acceptable process variation | Minimum acceptable performance level |
| Statistical Sampling | Choosing part of population for inspection | Testing 10% of production units |
| Pareto Diagram | Histogram ordered by frequency (80/20 rule) | 80% of defects from 20% of causes |
| Ishikawa Diagram | Cause and effect diagram (fishbone) | Root cause analysis tool |
| Verified Deliverables | Completed deliverables checked for correctness | Output of Control Quality process |
Scenario: A project has three possible outcomes:
Question: What is the Expected Monetary Value?
Solution:
Correct Answer: B) -$40,000
Scenario: A control chart shows the following defect counts: 12, 11, 13, 14, 15, 16, 17, 18. The Upper Control Limit is 20 and Lower Control Limit is 5.
Question: What should the project manager do?
Solution: The data shows seven consecutive points trending upward, which violates the "seven consecutive points trending up or down" rule, indicating the process is out of control.
Correct Answer: B) Investigate the process for special causes
| Strategy | Type | When to Use | Example |
|---|---|---|---|
| Avoid | Threat | High impact, unacceptable risk | Change scope to eliminate risk |
| Transfer | Threat | Others better positioned to manage | Insurance, outsourcing, warranties |
| Mitigate | Threat | Can reduce probability or impact | Training, prototyping, testing |
| Accept | Threat | Low priority or cost-effective option | Acknowledge and monitor |
| Exploit | Opportunity | Ensure opportunity happens | Add resources to finish early |
| Share | Opportunity | Partner can better capture opportunity | Joint ventures, partnerships |
| Enhance | Opportunity | Increase probability or impact | Incentives, additional resources |
| Accept | Opportunity | Take advantage if it occurs | Be ready but don't actively pursue |
| Tool | Purpose | When to Use | Output |
|---|---|---|---|
| Cause & Effect Diagram | Identify potential causes | Problem investigation | Fishbone diagram |
| Control Chart | Monitor process stability | Ongoing process monitoring | Process control status |
| Flowchart | Show process flow | Process analysis and design | Process diagram |
| Histogram | Show data distribution | Data analysis | Bar chart of frequencies |
| Pareto Diagram | Prioritize problems | Focus improvement efforts | 80/20 analysis |
| Scatter Diagram | Show variable relationships | Correlation analysis | Relationship strength |
| Checksheet | Collect data systematically | Data gathering | Organized data |
Memory Aid: "Please Identify People Performing Risk Implementation Monitoring"
Memory Aid: "Planning Management Control"
During project execution, a team member informs you that a key component may not be delivered on time due to supplier issues. This was not identified during risk planning. What should you do FIRST?
Correct Answer: A) Update the risk register and assess the impact
Explanation: When a new risk is identified during execution, the first step is to document it in the risk register and perform qualitative analysis to understand its impact before determining the appropriate response.
Your project has identified a risk that a new regulation might require additional compliance testing, potentially adding 3 weeks to the schedule. The probability is assessed as medium (0.5) and impact as high (0.4). What is the most appropriate response strategy?
Correct Answer: C) Mitigate by researching regulations and preparing contingency plans
Explanation: With a risk score of 0.2 (medium-high priority), mitigation is appropriate. Researching regulations and preparing contingency plans reduces both probability and impact.
During a quality audit, you discover that the team is not following the established testing procedures. Several defects that should have been caught have made it to the customer. What type of quality cost does this represent?
Correct Answer: D) External failure costs
Explanation: External failure costs occur when defects reach the customer. These include warranty costs, customer support, and potential lost business due to customer dissatisfaction.
A control chart shows the following pattern: 15, 14, 16, 15, 17, 18, 19, 20. The upper control limit is 22 and the mean is 16. What should the project manager conclude?
Correct Answer: C) The process is out of control due to trending
Explanation: The data shows seven consecutive points (14, 15, 16, 17, 18, 19, 20) trending upward, which violates the "seven consecutive points trending up or down" rule.
A project manager must choose between two vendors. Vendor A has a 70% chance of delivering on time at $100,000 cost and 30% chance of being late with additional $50,000 penalty. Vendor B has 90% chance of delivering on time at $120,000 and 10% chance of being late with $30,000 penalty. Which vendor should be selected based on EMV?
Correct Answer: A) Vendor A (EMV = $115,000)
Explanation:
Choose Vendor A with lower EMV ($115,000 vs $123,000).
During project execution, the lead developer has informed you that they will be leaving the company in two weeks. How should this be categorized and handled?
Correct Answer: B) As an issue that needs immediate action
Explanation: This is a current problem (issue), not a future uncertain event (risk). It requires immediate action such as knowledge transfer, hiring replacement, or reassigning work.
A software product meets all functional requirements and performs flawlessly but has a basic user interface with limited features. How would you characterize this product?
Correct Answer: B) High quality, low grade
Explanation: Quality relates to meeting requirements (high - meets all functional requirements), while grade relates to features and characteristics (low - basic interface, limited features).
Your project budget includes $50,000 for identified risks in the risk register and an additional $25,000 controlled by the sponsor for unplanned scope changes. What do these represent?
Correct Answer: C) $50,000 is contingency reserve; $25,000 is management reserve
Explanation: Contingency reserves are for known risks (identified in risk register), while management reserves are for unknown risks and unplanned scope changes, controlled by management/sponsor.
Background: You are managing the implementation of a new electronic health records (EHR) system for a 500-bed hospital. The project has a 18-month timeline and $5M budget.
Current Situation: Six months into the project, you identify the following situations:
Risk Analysis and Response Planning:
| Situation | Risk/Opportunity | Probability | Impact | Strategy | Response Actions |
|---|---|---|---|---|---|
| HIPAA regulation changes | Threat | Medium (0.6) | High (0.4) | Mitigate | Engage compliance expert, design flexible security architecture |
| Physician champion retirement | Threat | Certain (1.0) | Medium (0.3) | Mitigate | Identify and train replacement champion, document knowledge |
| Integration complexity | Threat | High (0.8) | High (0.4) | Mitigate | Escalate to vendor, consider alternative integration approach |
| Staff resistance | Threat | Medium (0.5) | Medium (0.3) | Mitigate | Enhanced change management, peer champions, incentives |
| Early HIE integration | Opportunity | High (0.7) | Medium (0.3) | Exploit | Accelerate HIE workstream |